1. Field of the Invention
This invention relates to processor systems and more particularly to interrupt processing and power management in processor systems.
2. Description of the Related Art
In general, an interrupt or exception is an event that changes instruction execution from a currently executing instruction flow to another instruction flow. An interrupt is typically generated by a processor or a device coupled to the processor. A typical interrupt processing mechanism changes program control flow of the interrupted processor to an interrupt handler.
Referring to FIG. 1, an exemplary processor system (e.g., system 100) includes at least one processor core (e.g., a central processing unit, core, a graphics processing unit or other processor that may include one or more cores, e.g., cores 102, 104, 106, and 108) configured to execute application threads. An exemplary interrupt delivery mechanism (e.g., an interrupt delivery mechanism of the x86 architecture) includes an interrupt controller (e.g., a local Advanced Programmable Interrupt Controller (APIC)) for each core in the system. In addition, an interrupt controller (e.g., I/O APIC 120) may be included for each peripheral bus in the system. A dedicated bus or a system bus (e.g., crossbar 116) may be used to communicate between APICs. In general, a local APIC (e.g., APIC 103, 105, 107, or 109) manages external interrupts for a corresponding core (e.g., core 102, 104, 106, or 108, respectively). A local APIC may be coupled to the same power plane as the system bus or a separate power plane. A typical local APIC supports a set of usable interrupt vectors, which correspond to interrupt priority and respective interrupt service routines. Another set of interrupt vectors is reserved for interrupt processing by the associated core.
Referring to FIGS. 1 and 2, an inter-processor interrupt is generated by a core (e.g., core 102) that writes to the Interrupt Control Register (ICR) in a corresponding local APIC (e.g., local APIC 103) (202). An ICR includes fields for a destination identifier, delivery mode, an interrupt vector, and other suitable information. Local APIC 103 generates an interrupt message and broadcasts the interrupt message through the on-chip network using crossbar 116 (204). A local APIC (e.g., local APIC 109) that receives the interrupt message determines whether to accept the interrupt based on a state of the associated core (e.g., core 108) and a state of the receiving local APIC itself (e.g., a delivery mode and a destination identifier). For example, if local APIC 109 has an identifier, physical ID, or logical ID that matches the destination ID according to the delivery mode, the local APIC 109 accepts the interrupt message, reads an interrupt vector number from the interrupt message, and a corresponding bit is set in an Interrupt Request Register (IRR) (not shown). Local APIC 109 sends an ACK (acknowledgement) message to local APIC 103 that originated the interrupt message to confirm the acceptance of the interrupt message by local APIC 109 (206).
An interrupt vector number read by an originating local APIC from the interrupt message represents a priority of the interrupt, which is compared to a priority of other pending interrupts and a priority of one or more currently executing threads. If the interrupt has the highest priority, the interrupt is delivered to a destination core. Logic in the originating APIC sends a message to the destination core (208). Receiving the message, the destination core detects the interrupt and at an instruction boundary of a currently executing application thread, the core executes an interrupt service routine. The interrupt service routine and program control is transferred to the interrupt handler, the destination core handles the interrupt by executing actions specified in the interrupt handler (212). Control returns from the interrupt handler and may return to a previously executing application thread, according to results of those actions specified by the interrupt handler (214).
Still referring to FIGS. 1 and 2, an interrupt from a device (e.g., device 122) coupled to a peripheral bus of system 100 is handled similarly to inter-processor interrupts, as described above. For example, in a network packet processing system, device 122 is a network interface card (NIC). When packets arrive, the NIC sends an interrupt to the processor to notify the processor of the arrival of the packets. Device 122 generates an interrupt by asserting an interrupt signal (202) and I/O APIC 120 generates an interrupt message with information, e.g., destination identifier, delivery mode, interrupt vector, or other suitable information. Then, the interrupt is broadcast to the local APICs (204). A destination local APIC sends an acknowledgement to the I/O APIC (206). The interrupt is delivered to the destination core corresponding to the destination local APIC. The destination core processes the interrupt (210, 212, 214) in the same way that a destination core processes inter-processor interrupts. A destination local APIC processes other sources of interrupts in a similar manner, e.g., timer interrupts, performance monitor counter interrupts, or interrupts from thermal sensors.
Processor power management techniques include configuring cores to enter low-power states during idle periods. For example, a low-power state may include supplying a lower voltage to a core power plane, disconnecting a core from its power plane, or a power supply turning off the core power plane entirely. If a destination core is in a low-power state, processor 100 may need to bring the destination core out of the low-power state in order to service an interrupt. Transitioning from the low-power state to a target power state sufficient to handle the interrupt typically increases interrupt service latency as a result of delays associated with ramping up the core power supply to a target voltage level and/or initializing or loading the architectural state of the core. In general, an increase in interrupt service latency decreases the performance of processor 100 and may decrease the quality of a user experience. As a result, processors designed to allow cores to enter low-power states during idle periods must also be able to bring cores out of the low-power states quickly in order to sufficiently service an interrupt destined for one of those cores. This rapid low-power-state exit has a high power cost and may not have sufficiently low interrupt service latency. Accordingly, techniques that reduce interrupt latency associated with power management techniques are desired.